home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 52 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.2 KB
  1. Subject: Re: Colour. 
  2. Date: Tue, 31 May 1994 10:29:48 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6. In message <9405301326.AA08685@phlem.ph.kcl.ac.uk>, you wrote:
  7. >
  8. >>         - When should a user desire to change [the std 16 colours]?
  9. >
  10. >I don't see this as our concern - if a user wishes to change the colours,
  11. >let him/her. Presumably (s)he has a good reason to do it...
  12.  
  13. It becomes an issue if an application wants to assume colours for colour
  14. icons.  [btw, hands up all those who think the colour icon extension is
  15. is technically deficient]
  16.  
  17.  
  18. >>     - Sharing colours
  19. >>         - No point each program allocating its own Purple
  20. >>         - When colours must be changed, it would be nice for
  21. >>            the actual palette change to be minimized (eg. purple
  22. >>            changes to dark purple, not green)
  23. >
  24. >The problem here is that GEM (unlike X) has no concept of shared colourmaps.
  25. >All colour resources are global. This is a pity, but I can't see Atari doing
  26. >anything about it. They could add the functionality to MultiTOS though.
  27. >(eg: send a WM_REMAPCOLS on a window change)
  28.  
  29. Indeed, a concurrent application could handle all colour changes.  All this
  30. colour-handling is really only an issue under MultiTOS, so such an application
  31. can easily be assumed (and if it doesn't exist, just hog colours like apps
  32. used to be able to do).
  33.  
  34.  
  35. >>     - True Colour emulations
  36. >>         - Some programs use a 5x5x5 or 6x6x6 colourspace, and
  37. >>            these should all be the same space.
  38. >
  39. >Perhaps we need the equivalent of Visuals on a app-by-app basis. So an app
  40. >could register its intent to use a 'type' of colourmap. So if we support
  41. >6x6x6 as PSEUDOTRUE, a STANDARD     256 and 16-entry (depending on display
  42. > depth)
  43. >colourmap, and a PRIVATE 256 & 16-entry colourmap, any app could know what
  44. >type of colourmap is currently selected, and on receiving WM_TOPPED, could set
  45. >its own colourmap if necessary.
  46.  
  47. If, as another poster suggested, WM_TOPPED messages are broadcast, then a
  48. colour server could handle all this without consultation with the app.
  49.  
  50.  
  51. >You'd end up with:
  52. >
  53. >        cmsPresent = 1;
  54. >        cmsRegister(PRIVATE);
  55. >        cmsSetPalette(depth, uchar *R, uchar *G, uchar *B);
  56. errr... shorts, not uchars.  0..1000, remember :)
  57. are these arrays shared memory?
  58. >        cmsChangePalette();
  59.  
  60.  
  61. >Of course, the main drawback is that no current apps will support this, but
  62. >since there isn't already a standard, I don't see that anything could get
  63. >around this.
  64.  
  65. And the sooner a good system can be formulated, the less non-conformant
  66. apps there will be.  We are lucky:  not many old apps use colour.  
  67.  
  68.  
  69. >I'm dubious about whether changing on manipulation is a good idea. I suppose
  70. >it is, but it makes implementation more difficult.
  71.  
  72. As more applications use a click-on-background-windows approach (and they
  73. will, as more people start using screens with sufficient space to have
  74. non-overlapping windows).  Falcon graphics, especially with BlowUp/etc,
  75. and graphics cards make this a reality.
  76.  
  77.  
  78. >A program (GEMCMS.PRG) in the auto folder could register the cookie, and
  79. >reserve mem for (say) 30 apps.
  80.  
  81. Forget auto prgs.  Think APPLICATIONS.  The CMS could simply be an application
  82. to which messages are passed.  Colour handling is only an issue under MultiTOS,
  83. so we can use a MultiTOS solution.  (or Geneva, of course)
  84.  
  85.  
  86. --
  87. Warwick
  88.